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The  Context 


Our  client  wanted  to  create  a  reference  architecture  to  enable  large- 
scale  strategic  reuse. 


A  major  long-term  effort  in  which  assets  are  to  be  produced  by  a  central 
team  and  used  by  distributed  teams. 


The  distributed  teams  are  independent  of  the  central  team. 


This  was  a  cultural  as  well  as  a  SE  challenge. 
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The  Problem 


The  client  needs  an  overarching  architectural  framework  if  the  project  is 
to  be  successful 

•  a  set  of  standards,  technologies,  ... 

•  more  importantly  a  set  of  rules  and  architectural  approaches. 


Without  the  rules  and  architectural  approaches  the  natural  tendency — 
with  large  numbers  of  quasi-independent  stakeholders,  each  with  their 
own  goals,  budgets,  and  schedules — is  towards  anarchy. 
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The  Techniques 


We  created  a  mashup  of  existing  SEI  architecture  methods  to  begin 
address  their  goal  of  creating  a  reference  architecture: 

.  QAW 

.  ADD 

•  Ecosystem  modeling 

•  Reference  Architecture 

•  Reference  Architecture  Documentation 

•  Continuous  ATAM 

ADD  and  Architecture  Definition  had  to  be  adjusted  to  produce  a 
reference  architecture. 

This  required  extensive  mentoring. 
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Scope 


The  scope  of  the  development  planned  by  the  various  teams  limits  the 
applicability  of  the  reference  architecture. 

In  our  case  the  scope  was  broadly  stated  in  an  ecosystem  model. 

Our  reference  architecture  needed  to  address  the  requirements  of  all 
products  in  the  ecosystem. 
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Ecosystem  Modeling 


For  an  ultra-large-scale  system — a  socio-technical  ecosystem — to  grow 
and  flourish,  it  needs  to  enable  creativity  while  minimally  restricting 
developers  and  users. 


The  internet  accomplishes  this  by  only  specifying  interconnectivity 
standards,  primarily  protocols  (e.g.  IP).  But  the  internet  has  no  “goal”. 


Commercial  ecosystems  accomplish  this  by  providing  a  “platform”  on 
which  individual  applications  are  built  and  deployed,  e.g.  iPhone, 
Android,  Facebook,  Eclipse,  etc. 


Our  program  is  establishing  an  ecosystem  around  a  centrally  provided 
platform  and  a  set  of  reusable  assets. 
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Software  Ecosystems 


A  software  ecosystem  has  a  “hub,”  which  provides  a  platform.  In  our 
case  the  core  asset  team  will  provide  an  platform  consisting  of  an  asset 
base  and  runtime  environment. 


Programs  of  Interest  will  obtain  resources  from,  and  contribute 
resources  to,  the  ecosystem. 


The  organization  at  the  hub  can  analyze  the  relations  in  the  ecosystem 
and  develop  strategies  that  enhance  ecosystem  health. 


Software  ecosystems  such  as  surrounding  the  open  source  Eclipse 
Foundation  and  that  surrounding  the  commercial  Microsoft  use  different 
governance  models.  Our  client’s  ecosystem  has  strict  hierarchical 
control  which  can  make  ensuring  architectural  conformance  easier. 
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Strategic  Ecosystem  Modeling  for  Decision  Making 


Each  development  team  is  the  hub  of  a  cluster  of  consumers  and 
suppliers  and  will  foster  competitors  and  alternatives. 


There  may  be  overlaps  where  organization  can  be  both  producers  and 
consumers  of  each  others  assets  and  products. 


Strategic  modeling  is  used  to  understand  the  ecosystem  and  to  guide 
decisions  to  enhance  that  ecosystem. 
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Quality  Attributes 


For  a  reference  architecture  the  quality  attribute  requirements  have  to  be 
defined 

•  in  a  sufficiently  broad  manner  to  address  the  complete  range  of  products  to 
be  covered  by  the  architecture  or 

•  in  a  narrowly  focused  manner  in  each  of  several  configurations  that  address 
specific  markets 

We  identified  a  few  system  categories  that  affected  quality  attributes: 

•  desktop 

•  mobile 

•  airborne 

For  example,  the  testability  and  security  requirements  of  each  of  these 
will  differ. 
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Inputs/Constraints 


Inputs  and  constraints  came  from  both  general  software  engineering 
techniques  and  problem-specific  information 

•  General 

-ADD  technique  definition 
-RUP  definition 

-  Documenting  Software  Architectures  book 

-  ISO/IEC/IEEEFDIS  42010 

•  Specific 

-QAW  outputs,  primarily  quality  attribute  scenarios 
-Additional  scenarios  developed  through  white  papers 
-Architectures  from  similar  systems 

-  Ecosystem  model  for  the  program 
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ADD  Steps 


T 


All  requirements  are  well-formed 
and  prioritized  by  stakeholders 


Step  1:  Confirm  there  is 
sufficient  requirements 


information 


I 


Step  2:  Choose  an  element  of  the  system  to 
decompose 


I 


Step  3:  Identify  candidate  architectural 
drivers 


I 


Step  4:  Choose  a  design  concept  that 
satisfies  the  architectural  drivers 


I 


Step  5:  Instantiate  architectural  elements 
and  allocate  responsibilities 


I 


Step  6:  Define  interfaces  for  instantiated 
elements 


I 


Step  7:  Verify  and  refine  requirements  and 
make  them  constraints  for  instantiated 
elements 


Key: 


Process 

step 
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Modifications  to  ADD 


The  emphasis  of  ADD  becomes  more  “conceptual”. 

The  “elements”  in  the  ADD  description  were  described  more  abstractly. 
Quality  attributes — but  not  specific  quality  goals — were  identified. 

Architecture  patterns  were  described  but  not  concretely  instantiated. 


Documentation  notation  (UML)  was  used:  architecture  elements  are 
abstractions  but  crisply  defined  abstractions  rather  than  vague  notions. 
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Outputs  from  ADD 


The  output  of  ADD  is  a  system  design  in  terms  of  the  roles, 

responsibilities,  properties,  and  relationships  among  software  elements. 

•  software  element  a  computational  or  developmental  concept  that 
fulfills  roles  and  responsibilities,  has  defined  properties,  and  relates 
to  other  software  elements  to  compose  the  system  architecture 

•  role :  a  set  of  related  responsibilities 

•  responsibility :  the  functionality,  data,  or  information  that  a  software 
element  provides 

•  property :  additional  information  about  a  software  element  such  as 
name,  type,  quality  attribute  characteristic,  protocol,  and  so  on 

•  relationship :  a  definition  of  how  two  software  elements  are  associated 
with  or  interact  with  one  another 
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“n”  Week  Review  Cycle 


We  used  ADD  in  an  iterative,  incremental  manner 
For  each  iteration: 

•  Assign  a  set  of  requirements 

•  Architecture  sub-team: 

•  designs  a  solution 

•  documents  it 

•  presents  it  in  a  review  following  the  peer  review  process 

•  Risks,  sensitivities,  tradeoffs  and  issues  are  analyzed  and  collected 

•  Revisions  are  planned 

•  Here  we  go  again 

Based  on  F.  Bachmann’s  “Give  the  Stakeholders  What  They  Want: 
Design  Peer  Reviews  the  ATAM  Style”,  Crosstalk 
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A  Starting  Point  for  a  Reference  Architecture 


The  client  has  adopted  the  Eclipse  Platform  as  the  basis  for  a  set  of 
development  environment  products: 

•  It  might  release  all  of  the  SDK  under  the  Eclipse  Public  License 
(EPL)  setting  up  an  environment  where  the  client  could  freely  provide 
the  SDK  to  all  teams. 

•  A  new  license  could  be  established  that  restricts  certain  activities  and 
gives  client  greater  control.  Paths  through  the  ecosystem  can  be 
examined  for  license  compatibility. 

To  ensure  that  the  identified  product  qualities  are  actually  achieved, 
information  needs  to  be  propagated  through  the  ecosystem.  Suppliers, 
whose  products  negatively  impact  quality,  need  to  be  notified  of  required 
quality  levels. 

The  ecosystem  can  be  the  basis  for  organizational  qualities  such  as 
performance  or  productivity. 
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Accomplishments 


Two  initial  releases  of  the  reference  architecture  have  been  made. 

Two  primary  foci 

•  the  basic  environment  -  Eclipse  Platform  plus 

•  communication  buses  -  2  buses  plus  gateways  to  link  instances  of 
both 

Overarching  risks  have  been  identified 

•  if  the  scope  is  too  narrowly  defined  there  is  a  risk  the  architecture  will 
be  inadequate 

•  if  the  concepts  in  the  reference  architecture  are  too  concrete  the 
architecture  may  not  be  sufficiently  flexible 
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Using  UML 
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Dual  Purpose 


Using  Eclipse  to  develop  the  architecture  description  had  the  additional 
benefit  of  getting  the  architects  familiar  with  the  Eclipse  IDE. 


Edit  Navigate  Search  Project  Scripts  Window  Help 

r3  -  y  ©  ca  <'  ■f  -  v  -  I  a*  &  s5  “s* 

Upstrea 


o??|  f 


i  OB  X I  100* 


B  [  m  UML/SysML  ]  ” 


[^3  Project  £3 


B  %  ' 


CJ  Honeywell 
Q  hunt 
Q  InfoAADL 
Cl  infotainment 
fcy  infotainmentModel 
&  Models 
&  tmp 

InfotainmentProblem.docx 
infollses.docx 
infotainment.pos 
{•£)  GetDirections.sysml 
GetDirections.sysmldi 
@  InfotainmentSystem.uml 
imb  InfotainmentSystem. umldi 
[§1  defaultvedit 
[sj  default.vedit_diagram 
,  '  infotainment.xdm 
8)  infotainmentjrfm 
1H  xfproject.xfp 
1  infotainment.xgc 
£|  xfbuild.xml 
Cl  jbcp 


f.  Model  E  £T\  Current  =  E3 

a*  ^  i\ 


No  Model  Available 


*model2.di  GetDirections.sysmldi  "InfotainmentSystem.umldi 


/infotainmentModel/InfotainmentSystem.umldi 
l~S  Select 
>  [J.  Marquee 
b  Note 
&  Objects 
&  Region 
«  State 

O  Composite  State 
C?  Submachine  State 
Q  ConnectionPointReference 
<S>  FinalState 
£>  Pseudostates 
&  Connections 

SjP  External  Transition 
°J  Local  Transition 


NoPower\tumPower0n 


1  Cj  Properties  Q  Documentation  |  (*_  Problems 

a  a  E  ”  °  g| 

©  Diagram  InfotainmentSystem 

InfotainmentSystem 


hsr  iP2i  h  'S  El 


=  Software  Engineering  Institute  Carnede Mellon  Kazman,  McGregor 

W  W  O  (cl  OHIO  <~ai-nonio  Mallr.n  I  Inc 


SATURN  2012 


©2012  Carnegie  Mellon  University 


Results  and  Observations  -  Challenges 


Architects  gave  too  much  detail  -  implementation  versus  architecture. 


Constantly  got  wrapped  up  in  functionality  and  forgot  QAs  until 
reminded. 

They  wanted  strategic  reuse  but  they  were  operating  tactically;  they 
failed  to  see  the  ecosystem  as  charting  strategic  directions. 


Reference  architecture  is  a  long-term  strategy  and  the  team  continued 
with  a  short-term  view. 


Explaining  the  value  of  strategy  to  tactical  engineers  is  difficult. 


Software  Engineering  Institute  CarnegieMellon 


SATURN  2012 
Kazman,  McGregor 

©2012  Carnegie  Mellon  University 


Result  and  Observations  -  Wins 


They  have  existing  architectures  and  deep  experience.  But  they  were 
very  focused  on  their  own  legacy  and  details. 


Now  teams  are  beginning  to  focus  on  architectural  concepts;  amount  of 
“useless”  (i.e.  implementation,  short-term  focused)  material  generated 
has  decreased. 


They  have  begun  to  use  architecture  concepts  as  vocabulary,  e.g.  using 
a  “gateway  pattern”  to  generalize  different  bus  protocols. 

Starting  to  realize  what  should  go  into  the  architecture  documentation. 

Moving  toward  the  goal  of  a  single  reference  architecture. 
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Conclusions 


Creating  a  reference  architecture  is  hard. 


This  required  experienced  architects  to  think  differently!  None  of  them 
had  ever  described  or  even  used  a  reference  architecture  before. 


To  meet  this  challenge  we  had  to  tailor  and  combine  a  number  of 
existing  architecture  creation,  analysis,  and  description  methods. 


Early  results  from  this  mashup  are  promising. 
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